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@ The present invention provides a method and 
system in a data processing system, having a mul- 
titasking operating system which includes a plurality 
of processes, for providing communication between 

a objects executing within the processes in the mul- 
titasking operating system, the method and system 
^ includes registering an object within a communica- 
0> tions manager in response to a launching of the 
O object. The communications manager monitors all 
^ objects registered with the communications manager 
0> within the plurality of processes. A determination of 
^ whether a first object is registered is made utilising 
O the communications manager, In response to receiv- 
^ ing a request from a second object to send a mes- 

lU 



sage to the first object; Automatic initiation of the 
launching the first object within the processes is 
performed if the first object is unregistered utilising 
the communications manager. Next, the first process 
containing the first object is bound to the second 
process containing the second object, wherein a 
communications path Is established between the first 
process and the second of the process. The mes- 
sage is sent to the first object from the second 
object via the established communications path be- 
tween the two processes, wherein communication 
between the first object and the second object is 
automatically established. 
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Technical Field 

The present invention relates In general to a 
method and system for managing communications 
in a data processing system and in particular to a 
method and system for managing communications 
between objects executing different processes in a 
data processing system. 

Background Art 

In multi-tasking operating systems, hardware 
may be managed as a shared resource to be 
distributed among concurrently executing applica- 
tions or programs. In a multi-tasking operating sys- 
tem, resources such as the processor, memory, 
files, devices and inter-process communications 
structures are also shared in the operating system 
among concurrently executing applications, pro- 
grams, or objects. "TImeslicIng" is utilised to share 
the processor with various concurrently executing 
applications or objects. Generally, an operating 
system will switch between applications allowing 
each application to run for a short period of time, a 
"timeslice". Thus, In this manner, the processor 
may be shared between various applications or 
objects, enabling multitasking. 

For example, OS/2 is an operating system that 
offers a multitasking architecture, providing the ca- 
pability to execute multiple programs in a protected 
environment. OS/2 is a trademark and a product of 
International Business Machines Corporation. OS/2 
Includes a hierarchy of multi-tasking options called 
sessions, processes, and threads. A "session" is a 
unit of user input/output ("I/O") device sharing. A 
"process" is a unit for sharing for various re- 
sources, such as memory, files, semaphores, 
queues, and threads. A process may contain mul- 
tiple programs or objects. More information on 
OS/2 can be found In a text entitled The Design of 
OS/2 by Deitel and Kogan, published by Addlson- 
Wesley Publishing Co. 1992. 

Objects are DCE objects as defined in OSF 
DCE User's Guide And Reference from The Open 
Software Foundation Inc. located at 11 Cambridge 
Center, Cambridge, Massachusetts 02143. In an 
environment containing different and potentially in- 
dependent application objects (all of which are built 
upon a base class hierarchy), which are being 
developed, a need exists to decouple the run-time 
environments in which the objects execute. The 
need for decoupling arises out of a concern for 
integrity between the objects. Generally, if two ob- 
jects are executing within the same process, the 
failure of one object will jeopardise the other ob- 
ject. In other words, if one object fails within a 
process, normally all of the other objects within the 
same process will also fail or become unstable. An 



erroneous implementation of one object also may 
corrupt the other objects. 

Objects executing within the same process are 
able to easily exchange data. Frequently, it Is de- 

5 sirable to interchange data or send messages to an 
object within a different process. Data exchange 
becomes more difficult between objects executing 
in different processes. 

Presently, data sharing and message sending 

10 between two objects, located in different pro- 
cesses, are handled by writing a protocol specific 
to the two objects. As a result, data sharing and 
message sending may only occur between those 
two objects. In order to add a third object, addi- 

75 tional code must be produced to allow for data 
sharing and message sending between all three 
objects. 

Therefore, it would be desirable to have a 
method and system to manage the distribution and 
20 communication of data and messages across pro- 
cesses without having to produce new protocols for 
each additional process. 

Disclosure of the Invention 

25 

It is therefore one object of the present inven- 
tion to provide a method and system for managing 
communications in a data processing system. 
It is another object of the present invention to 

30 provide a method and system for managing com- 
munications between objects executing within a 
data processing system. 

It Is yet another object of the present invention 
to provide a method and system for managing 

35 communications between objects executing In dif- 
ferent processes within a data processing system. 

The foregoing objects are achieved as is now 
described. The present Invention provides a meth- 
od and system in a data processing system, having 

40 a multitasking operating system that includes a 
plurality of processes, for providing communication 
between objects executing within the processes In 
the multitasking operating system. The method and 
system includes registering an object with a com- 

45 munications manager in response to a launching of 
the object. The communications manager monitors 
all objects registered to it within the plurality of 
processes. A determination of whether a first object 
Is registered Is made utilising the communications 

50 manager, in response to receiving a request from a 
second object to send a message to the first ob- 
ject. Automatic initiation of the launching the first 
object within the processes Is performed utilising 
the communications manager if the first object is 

55 unregistered. Next, the process containing the first 
object is bound to the process containing the sec- 
ond object, wherein a communications path is es- 
tablished between the two processes. The mes- 

3 



WEST 



3 



EP 0 592 091 A2 



4 



sage is sent to the first object from the second 
object via the communications path between the 
two processes, wherein communication between 
the first object and the second object is automati- 
cally established. 

Brief Description of the Drawings 

The invention will now be described, by way of 
example only, with reference to the acconnpanying 
drawings, in which: 

Figure 1 depicts a pictorial representation of a 
data processing system which may be utilized 
to implement a method of the present invention; 
Figure 2 is a diagram illustrating the establish- 
ment of a communications link between an ob- 
ject dispatch process (ODP) and a process in 
accordance with a pretended embodiment of the 
present invention; 

Figure 3 depicts a data flow diagram illustrating 
the establishment of a communications link be- 
tween two processes in a situation where one 
object has not been instantiated in accordance 
with a preferred embodiment of the present in- 
vention; 

Figures 4A and 4B are logical flowchart for 
creating a communications path in accordance 
with a preferred embodiment of the present in- 
vention; and 

Figure 5 depicts a logical flowchart of the pro- 
cess followed by a message dispatcher (MD) in 
accordance with a pretended embodiment of the 
present invention. 

Detailed Description of the Invention 

With reference now to the figures, and in par- 
ticular with reference to Figure 1, there is depicted 
a pictorial representation of a data processing sys- 
tem 8 that may be utilised to implement a method 
and system of the present invention. As may be 
seen, data processing system 8 may include a 
plurality of networks, such as local area networks 
(LAN) 10 and 32, each of which preferably includes 
a plurality of individual computers 12 and 30, re- 
spectively. Of course, those skilled in the art will 
appreciate that a plurality of intelligent work sta- 
tions (IWS) coupled to a host processor may be 
utilised for each such network. 

As is common in such data processing sys- 
tems, each Individual computer may be coupled to 
a storage device 14 and/or a printer/output device 
16. One or more such storage devices 14 may be 
utilised, to store documents or resource objects 
which may be periodically accessed by any user 
within data processing system 8. In a manner well 
known in the prior art. each such document or 
resource object stored within a storage device 14 



may be freely interchanged throughout data pro- 
cessing system 8 by transferring a document to a 
user at an individual computer 12 or 32, for exam- 
ple. 

5 Still referring to Figure 1, it may be seen that 

data processing system 8 may also include mul- 
tiple mainframe computers, such as mainframe 
computer 18, which may be preferably coupled to 
LAN 10 by means of communications link 22. 

10 Mainframe computer 18 may also be coupled to a 
storage device 20 which may serve as remote 
storage for LAN 10. Similariy, LAN 10 may be 
coupled via communications link 24 through a sub- 
system control unit/communications controller 26 

75 and communications link 34 to a gateway server 
28. Gateway server 28 is preferably an individual 
computer or IWS which serves to link LAN 32 to 
LAN 10. 

As discussed above with respect to LAN 32 

20 and LAN 10, a plurality of documents or resource 
objects may be stored within storage device 20 
and controlled by mainframe computer 18, as Re- 
source Manager or Library Service for the resource 
objects thus stored. Of course, those skilled in the 

25 art will appreciate that mainframe computer 18 may 
be located a great geographic distance from LAN 
10 and similariy LAN 10 may be located a substan- 
tial distance from LAN 32. For example, LAN 32 
may be located in California while LAN 10 may be 

30 located within Texas and mainframe computer 18 
may be located in New York. 

A multitasking environment including multiple 
processes may be found on individual computers 
12 and 30. on gateway server 28, on some com- 

35 puter in LAN 10 or 32, or on mainframe computer 
18. 

An object management system is utilized to 
manage communications across processes and to 
track and locate objects executing within the pro- 

40 cesses in the multitasking environment. The object 
management system includes an object dispatcher 
process (ODP) and a message dispatcher (MD). 
This management system may include: (1) a 
launching mechanism to launch or initiate the 

45 launching of an object within a process. (2) a 
mechanism for grouping objects within a process, 
(3) a location mechanism to locate the process 
within which an object is executing, and (4) a 
system for forwarding messages. 

50 An object is identified by a static identity and a 
dynamic Identity. The "static identity" is the DCE 
name of the object, i.e., its spatial identification. For 
example, /.../austln.ibm.com/host/objl Identifies 
"objl" as an object in the "host" subdirectory of 

55 "austin.ibm.com" cell. Next, the "dynamic Identity" 
of an object is defined by a process-ID and a 
pointer. 
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The object management system monitors the 
objects within the various processes and maintains 
a local registry of all active objects. An object 
requesting a communications path to a target ob- 
ject utilizes a static identity to Identify the target 
object. An object locator component of the object 
management system in the ODP is utilized to Iden- 
tify the dynamic identity of an object that cor- 
responds to the static identity of the object. A 
mapping table is employed in the ODP to track and 
monitor objects registered to the ODP. If an entry 
for the name of an object is absent from the 
mapping table, the ODP launches or initialises the 
launching of the object. The ODP registers an 
object when the ODP launches the object. Reg- 
istration also occurs when an object communicates 
with the ODP. 

Three pieces of information are required to 
launch an object: (1) object identity. (2) class of the 
object, and (3) object handler. With an object Iden- 
tity, the static identity is sufficient if the object is 
not yet active. The object handler includes the 
code corresponding to the methods of the object. 

The ODP is a pivotal process in the method 
and system utilised to initiate and manage inter- 
object communication across processes and also 
may provide an "object locator" service. The ODP 
is a communications manager and constantly moni- 
tors for messages on a well-known port. Each 
communications path or channel to the ODP from a 
process is serviced by a "receiver thread", which 
is responsible for receiving a message on the ap- 
propriate path, decoding the message, and taking 
or initiating appropriate actions. A "receiver thread" 
is a thread within the ODP. Appropriate actions 
such as launching or initiating the launching of 
objects and creating communication paths or chan- 
nels between processes are examples of actions 
taken by the receiver thread. 

A message received by the ODP may include 
the following components: (1) object name. (2) 
class, (3) operation, and (4) arguments. An opera- 
tion may be, for example, to find and load an 
object, to create a new instance of an object, or 
may be any other operation that is defined in an 
object* s object handler. The object name is the 
name of the object that is to receive a message. 
The class is the class of that object. ODP registers 
objects that It launches and objects that commu- 
nicate with the ODP. 

The MD may manage inter-process and Intra- 
process communication between objects. It is re- 
sponsible for delivering messages or methods to 
objects within the process In which the MD is 
located. Incoming messages from another process 
are handled by forwarding them to the appropriate 
object by utilizing the object handle field within the 
message. 



When a local object sends a message to a 
foreign object, located In a different process and no 
communications path has been established be- 
tween the two processes, the MD sends the mes- 

6 sage to the ODP to establish a communications 
path to the process containing the foreign object. 
The ODP searches the mapping table to determine 
if an entry for the foreign object exists. 

In the event that an entry exists, the ODP 

10 extracts the dynamic identity (process-ID and han- 
dle within the process) of the foreign object from 
the mapping table. The handle within a process is 
utilised to Identify an object within the process. The 
ODP sends the message to the foreign object and 

15 returns a message to the requesting process that 
contains the method name, argument list, and a 
handle within the process for the foreign object. 
The MD of the local object utilises this information 
to send a message to the foreign object via a 

20 communications path or channel. 

If the ODP does not find an object entry in the 
mapping table, the ODP searches a class table to 
determine whether or not the foreign object's class 
has been loaded into any process. If it has, a 

25 message is sent to that process to launch the 
foreign object. The message sent to the process 
may be in the format: (operation, argument list, 
class name, a DLL name). DLL stands for Dynamic 
Link Library. If the class of the foreign object has 

30 not been loaded into a process, a new process is 
started and the foreign object is launched within 
the new process. 

In launching a object, it is assumed that the 
DCE name of the object Is known as well as the 

35 class of the object and the name of the object 
handler for the object. The object handler of the 
object Is the name of the dynamic link library (DLL) 
file in OS/2. A DLL is a set of subroutines that are 
dynamically bound to the calling program or object 

40 when the program or object is loaded into memory 
or when they are loaded explicitly by an already 
executing program or object. The DLL file contains 
the methods that the foreign object will respond to. 
More Information on DLL calls may be found in La- 

45 Garde et al., IBM Operating System/2 Version 1.2 
Programming Guide, International Business Ma- 
chines Corporation, Document No. 00F8833, 1989 
and In a text entitled The Design of OS/2 by Deitel 
and Kogan. published by Addison-Wesley Publish- 
so IngCo. 1992. 

In the situation where a communications path 
has already been established between the process 
containing a local object and the process contain- 
ing the foreign object, the invocation of an opera- 

55 tion on a foreign object by a local object results in 
the MD constructing the necessary message and 
fon^varding It directly to the process that is execut- 
ing the foreign object over the communications 
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path that was previously set up. MD maintains two 
tables for managing inter-process and intra-procass 
communications: (1) class table and (2) object ta- 
ble. The class table is a data structure that main- 
tains a list of all classes that are registered in a 
particular process. The object table is a table for 
storing a list of all objects existing within a particu- 
lar process and foreign objects that are in commu- 
nication with these objects. As a result, MD also 
provides a grouping mechanism to group objects 
within a process. 

Foreign objects are associated with binding 
information and channel identification that is neces- 
sary for reaching a foreign object. Channel iden- 
tification is data that uniquely identifies a commu- 
nications channel between a sender and a receiver. 
For example If a "sockets" implementation is being 
utilised for communication, a port number would 
uniquely identify the communications channel and 
if "shared memory" is employed for communica- 
tion, the name of the shared memory segment 
would uniquely identify the communications chan- 
nel. The MD also continuously "pings" or monitors 
the ODP to see if the ODP is currently executing. If 
MD determines through a time out mechanism that 
ODP is no longer running, it initiates a "clean up" 
and terminates itself. Referring now to Figure 2, 
there is depicted a diagram Illustrating the estab- 
lishment of a communications fink between an ODP 
and a process. ODP 200 scans port 202 for re- 
quests from other processes or subsystems, such 
as process 204, to connect to ODP 200. A sub- 
system is a logical subcomponent of a larger sys- 
tem, e.g., a file system in a operating system. Port 
202 is a port known to those skilled in the art and 
may be associated with a well known server pro- 
cess (I.e., name server, file-transfer protocol server, 
etc.). "Known" ports are those that are active on all 
machines. In a network of computers, a process on 
a machine may be identified by a pair: (machine- 
ID, port number). The port number identifies a 
process on a given machine. 

In response to such a request, ODP 200 re- 
turns a "binding" to the requesting process, pro- 
cess 204. The new binding represents a new com- 
munications path or channel, channel 206, between 
the process 204 and ODP 200. ODP 200 utilises 
this channel in all subsequent interaction with pro- 
cess 204. 

As mentioned before, each of the communica- 
tions paths or channels associated with the ODP 
are serviced by a "receiver" thread. This thread is 
responsible for receiving the message on the ap- 
propriate path or channel, decoding the message, 
and taking or initiating the appropriate action. Mes- 
sages received by ODP Include object name, class, 
operation, and arguments. 



With reference now to Figure 3 , there is de- 
picted a data flow diagram illustrating the establish- 
ment of a communications link between two pro- 
cesses in a situation where one object has not 
5 been Instantiated. Object 250 of class A Is execut- 
ing in process 252. Object 250 attempts to Instan- 
tiate a new object, Obj2, of class B, MD 254 
searches it's local class table and does not find 
class B. 

10 Consequently, MD 254 sends a message to 
ODP 256 via communications path 258, asking 
ODP 256 to instantiate Obj2 of class B. Commu- 
nications path 258 may be established as pre- 
viously illustrated in Figure 2. ODP 256 decodes 

75 the message and looks in its mapping table 257 for 
Obj2. Assuming ODP 256 does not find Ob]2 In 
mapping table 257. ODP 256 then obtains the 
name of Obj2's class from the message. 

ODP 256 initiates process 260 with class B 

20 loaded in it. MD 261 in process 260 instantiates or 
launches Ob]2 and returns Obj2_Handle and a 
new binding to ODP 256 to form communications 
path 262. ODP 256 updates mapping table 257 to 
include the association between Obj2 and 

25 Obj2_Handle. 

ODP 256 returns binding to MD 254 to estab- 
lish communications path 264. The MD 254 up- 
dates its local object table to associate Obj2 with 
the communications path to process 260 and re- 

30 turns a local handle for Obj2 to Object 250, forming 
communications path 264. All subsequent oper- 
ations on Obj2 by objects in process 252 are sent 
directly to process 260 over communications path 
264, 

35 Referring now to Figure 4A and Figure 4B, 
there is depicted a logical flowchart for creating a 
communications path. The procedure begins as 
Illustrated in block 400 and thereafter proceeds to 
block 402, which depicts the sending of a request, 

40 MO, to the ODP by a requesting object, which is 
the client of the ODP, to create a communications 
path to a target object. MO is a message, contain- 
ing the following information on the target object: 
(1) object name, (2) object class, (3) method name, 

45 (4) an argument list, and (5) a DLL file name. MO 
identifies the object utilising a static identity. The 
procedure then proceeds to block 404, which illus- 
trates the reception of the message, MO, by the 
ODP, the decoding of the message, MO, and the 

50 looking up of the object name In a mapping table 
by ODP. 

Next, the procedure then proceeds to block 
406. which depicts a determination of whether or 
not an object name has been found in the ODP*s 
55 mapping table corresponding to the object name 
specified in MO. The mapping table contains an 
entry for each object that Is registered with the 
ODP. Each entry contains: (1) object name, (2) 
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process-ID, and (3) handle within the process in 
which the object is found. As mentioned before, 
objects are registered when they send a request to 
the OOP or when the ODP launches an object If an 
object name has been found, the procedure then 
proceeds to block 408, which Illustrates the extrac- 
tion of a tuple (process-ID, handle within process) 
from the mapping table and corresponding the 
tuple to the object name in MO. 

Afterward, the procedure proceeds to block 
410, which depicts the sending of a message, Ml, 
to the MD in the process containing the target 
object. The message, Ml, contains the method 
name, an arguments list, and the handle within the 
process. Ml contains the dynamic identity of the 
object. The procedure then proceeds to block 414. 
which illustrates the MD in the process of the target 
object receiving the message. The message in- 
cludes the method name, an argument list, and the 
handle within the process for the object requested 
by the requesting object. Thereafter, the procedure 
proceeds to block 430 via connector C, which 
illustrates the return of a binding by the ODP to the 
client for the process containing the target object. 
Binding information is found within a connection 
table in the ODP. The connection table includes a 
process-ID associated with binding information for 
a particular process. This connection table is utilis- 
ed to provide binding information to various objects 
requiring communication's paths to objects in other 
processes. The process thereafter terminates as 
illustrated in block 432. 

Referring back to block 406, if an object name 
is not found in the mapping table, the procedure 
proceeds to block 416, which illustrates the search- 
ing of a class table for the object class of the target 
object requested. The procedure then proceeds to 
block 418, which depicts a determination of wheth- 
er or not the class is found in the class table in the 
ODP. The class table contains information on the 
object class and the process-ID associated with 
each object class. A class is registered when an 
object contacts the ODP if the class is not already 
in the class table. A class is also registered if the 
ODP launches or initiates the launching of a new 
process having a class not found in the ODP's 
class table. If the class is found, the procedure 
proceeds to block 419, which Illustrates the extrac- 
tion of a class-ID for the target object's class from 
the class table. Thereafter, the procedure continues 
to block 420 in Figure 4B via connector A. Block 
420 Illustrates the extraction of the process-ID in 
which the class of the target object Is loaded. 
Thereafter, the procedure proceeds to block 422, 
which depicts the sending of a message, M2, to 
the process In which the class of the target object 
is loaded. The message, M2, contains (1) the ob- 
ject class, (2) opn = new, and (3) the DLL of the 



target object. M2 Is a request to launch the target 
object in the process. Next, the procedure pro- 
ceeds to block 424, which Illustrates waiting for a 
reply from the process in which the class of the 

5 target object Is loaded. 

Thereafter, the procedure proceeds to block 
426, which depicts the reception the process-ID 
and the handle of the newly created target object 
from the process In which the class Is loaded. The 

10 procedure then proceeds to block 428, which illus- 
trates the registration of the target object and its 
handle into the mapping table by the ODP. The 
procedure proceeds to block 430, which depicts 
the ODP returning a "binding" to the process of 

15 the newly created target object. As a result, future 
requests for the target object by the requesting 
object may be directly sent to the process contain- 
ing the target object, and thus, bypassing .the ODP 
and thereby increasing performance and speed of 

20 communications between objects. The procedure 
then terminates as illustrated in block 432. 

Referring back to block 418. if a class is not 
found In the class table, the procedure then pro- 
ceeds, via connector B, to block 433, which illus- 

25 trates the initiation or launching of a new process 
and the loading of the class of the target object into 
the new process utilising the class name extracted 
from the request from the requesting object. The 
procedure advances to block 434, which depicts 

30 the registration of the class name and the process- 
ID of the new process into the class table in the 
ODP. 

Thereafter, the procedure proceeds to block 
422, which depicts the sending of a message, M2, 

36 to the new process. As described above, M2 con- 
tains the target object class, opn = "new", and the 
DLL of the target object. The procedure next ad- 
vances to block 424, which illustrates waiting for a 
reply from the process. Afterward, the procedure 

40 continues to block 426. which depicts the returning 
of the process-ID and the handle of the newly 
created target object by the process to the ODP. 
The procedure then proceeds to block 428, which 
illustrates the registration of the target object and 

45 its handle into the mapping table by the ODP. The 
procedure next proceeds to block 430, which de- 
picts the return of a "binding" for the process to 
the requesting object by the ODP. Again, the pro- 
cedure then terminates as depicted in block 432. 

50 Referring now to Figure 5. there is depicted a 
logical flowchart of the process followed by a mes- 
sage dispatcher (MD). As illustrated the procedure 
begins in block 500 and thereafter proceeds to 
block 502, which depicts the reception of a mes- 

55 sage and the decoding of the message by the MD. 
Thereafter, the procedure proceeds to block 504, 
which illustrates a determination of whether or not 
opn equals "new". If opn does not equal "new" the 
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procedure advances to block 506, which depicts 
the extraction of the handle, method name, and 
argument list from the message and utilising a 
system object model (SOM) dispatch to deliver the 
message to the object. SOM is a mechanism utilis- 
ed to deliver messages to objects within the same 
process. SOM is found in the OS/2 2.0 Software 
Development Toolkit (SDK) available from Interna- 
tional Business Machines Corporation. 

Thereafter, the procedure proceeds to block 
508, which illustrates the returning of the results to 
the object sending the message. The procedure 
then tenninates as depicted in block 510. 

Referring again to block 504, if "opn" equals 
"new", the procedure then proceeds to block 512, 
which illustrates using the object DLL to load the 
class into the process. Thereafter, the procedure 
proceeds to block 514, which depicts the invoca- 
tion of SOM dispatch on the above "class object" 
to create a new object. The procedure proceeds to 
block 516, which illustrates the sending of a reply 
to ODP to register the newly created object into 
OOP's mapping table. The procedure again Xerm\- 
nates as Illustrated in block 510. 

Claims 

1. A method for use in a data processing system 
(8). having a multitasking operating system 
which includes a plurality of processes (252, 
260). for providing communication between a 
plurality of objects (250, Obj2) executing within 
said plurality of processes in said multitasking 
operating system, said method comprising the 
steps of: 

registering (402) an object (250) with a 
communications manager (256) in response to 
a launching of said object by an object man- 
ager (256); 

determining (406) whether a first object 
(Obj2) is registered with said communications 
manager, in response to receiving a request 
from a second object (250) within said plurality 
of processes to send a message to said first 
object; 

automatically initiating launching (433) of 
said first object within said plurality of pro- 
cesses utilising said communications manager 
if said first object is unregistered; 

binding (430) a first (260) of said plurality 
of processes containing said first object (Obj2) 
to a second (252) of said plurality of processes 
containing said second object (250), wherein a 
communications path (264) is established be- 
tween said first of said plurality of processes 
and said second of said plurality of processes; 
and 

sending said message to said first object 



(Obj2) within said first (260) of said plurality of 
processes from said second object (250) in 
said second (252) of said plurality of processes 
via said established communications path 
5 (264) between said first of plurality of pro- 

cesses and said second of plurality of pro- 
cesses, wherein communication between said 
first object and said second object is automati- 
cally established. 

'0 

2. A method as claimed In claim 1 further com- 
prising registering an object (250) in response 
to a request for communication with said com- 
munications manager (256) by said object. 

75 

3. A method as claimed in claim 2, wherein said 
communications manager (256) registers an 
object (250) by storing data for an object within 
a mapping table (257), wherein said mapping 

20 table contains an entry for each object regis- 
tered by said communicafions manager. 

4. A method as claimed in claim 3, wherein said 
entry includes an identifier identifying the pro- 

25 cess (252) in which said registered object 
(250) has been launched. 

5- A method as claimed in claim 4, wherein said 
entry further Includes a pointer to said object 
30 (250). 

6. A method as claimed In claim 5. wherein said 
binding (430) of said first (260) of said plurality 
of processes to said second (252) of said 

35 plurality of processes includes sending said 

second of said plurality of processes binding 
data for said first of said plurality of processes. 

7. A method as claimed in claim 6, wherein each 
40 of said plurality of processes includes a mes- 
sage dispatcher (254, 261) for managing com- 
munications within a process and between pro- 
cesses, wherein said message dispatcher has 
a communications path (262) to said commu- 

45 nications manager (256). 

8. A method as claimed in claim 7. wherein said 
message dispatcher (254, 261) for a process 
(252, 260) maintains a data structure having a 

50 list of ail objects (250. Obj2) within said pro- 

cess and all objects in other processes having 
a communicafions path (264) to said process. 

9. A method as claimed in any previous claim, 
55 wherein said communications manager (256) 

monitors all objects (250) registered to said 
communications manager within said plurality 
of processes (252, 260); and further compris- 
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ing: 

prior to automatically Initiating launching 
(433) of said first object, automatically search- 
ing (416) said plurality of processes for a pro- 
cess containing a class for said first object 5 
within said plurality of processes if said first 
object Is unregistered and if a process contain- 
ing said class is present. 

10. A data processing system (8), having a mul- io 
titasking operating system which includes a 
plurality of processes (252, 260). for providing 
communication between a plurality of objects 
(250, Obj2) executing within said plurality of 
processes in said multitasking operating sys- 75 
tem, said data processing system comprises: 

registration means (402) for registering an 
object (250) with a communications manager 
(256) in response to a launching of said object 
by said object manager (256); 20 

determining means (406) for determining 
whether a first object (Obj2) is registered with 
said communications manager in response to 
receiving a request from a second object (250) 
within said plurality of processes to send a 25 
message to said first object; 

initiation means (433) for automatically ini- 
tiating launching of said first object within said 
plurality of processes utilising said commu- 
nications manager if said first object is un- ao 
registered; 

binding means (430) for binding a first 
(260) of said plurality of processes containing 
said first object (Obj2) to a second (252) of 
said plurality of processes containing said sec- 35 
ond object (250), wherein a communications 
path (264) is established between said first of 
said plurality of processes and said second of 
said plurality of processes; and 

sending means for sending said message 40 
to said first object {Obj2) within said first (260) 
of said plurality of processes from said second 
object (250) in said second (252) of said plural- 
ity of processes via said established commu- 
nications path (264) between said first of plu- 4S 
ratlty of processes and said second of plurality 
of processes, wherein communication between 
said first object and said second object is 
automatically established. 

50 



55 



WEST 



EP 0 592 091 A2 




10 

WEST 



EP 0 592 091 A2 




Fig. 2 



11 



WEST 



EP 0 592 091 A2 




12 



WEST 



EP 0 592 091 A2 



LOOKUP CLASS 
TABLE FOR 

OBJECT CLASS 



416 




EXTRACT 
CLASS-ID FOR 
CLASS FROy 
CLASS TABLE 




© 



( START 



400 



I 



CLIENT SEND 
SENDS REQUEST 
TO OOP 



If 



402 



OOP RECEIVES & 
DECODES yESS- 
AGE k LOOKS UP 
OBJECT NAyE IN 
yAPPING TABLE 



■404 




408 



EXTRACT 
TUPLE FROy 
yAPPING TABLE 
CORRESPONDING 
TO OBJECT NAyE 



SEND yESSAGE 
TO PROCESS 



yO IN PROCESS 
RECEIVES 
yESSAGE 



1/ 



410 



414 




Fig, 4A 



13 
WEST 



EP 0 592 091 A2 



420-^. 



422 



426 



428->y. 



430 



EXTRACT 
PROCESS 10 IN 
WHICH CLASS 

IS LOAOCD 



SEND MESSAGE. 
U2, TO PROCESS 



WAIT FOR REPLY 
FROU PROCESS 



RECEIVE PROCESS 
ID AND HANDLE 
OF NEWLY 

CREATED OBJECT 
FROy PROCESS 



I 



OOP REGISTERS 

OBJECT AND 
ITS HANDLE INTO 
MAPPING TABLE 



9 



START A NEW 
PROCESS AND LOAD 
CLASS INTO IT 
UTILIZING THE 
" DLL NAME " 
EXTRACTED FROM MO 



if 



433 



REGISTER THE 
CLASS NAME AND 
PROCESS ID 
INTO THE GDP 
CLASS TABLE 



434 



OOP RETURNS A 
" BINDING " 
FOR PROCESS 
TO CLIENT 



432 



Fig. 4B 



14 

WEST 



EP 0 592 091 A2 



500 



j-502 



I 



MD RECEIVES AND 
DECODES UESSACE 




EXTRACT HANDLE. 

METHOD NAME. 
ARGUMENT LIST ft 
USE SOU DISPATCH 
TO DELIVER METHOD 
TO OBJECT 



506 



USE OBJECT DLL 
TO LOAD CLASS 
IN THIS PROCESS 



I 



508 



RETURN RESULTS 



INVOKE 
" SOMDISPATCH " 
ON CLASS OBJECT 
TO CREATE A 
NEW OBJECT 



I 



if 



514 



SEND REPLY TO 
OOP TO REGISTER 
NEWLY CREATED 
OBJECT INTO OOP 

MAPPING TABLE 



if 



516 



C 



END 



SIO 



Fig. 5 



15 
WEST 



